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1.0  INTRODUCTION 


1.1  ABSTRACT 

This  rqnct  describes  lessons  teamed  fiom  die  first  phase  of  a  domain  analysis  reseaich 
project  perfonned  for  die  Office  of  Naval  Research.  The  goal  of  diis  project  is  to  evaluate  die 
current  state  of  die  art  in  die  emoging  field  of  dmnain  analysis  and  emfdoy  modem  domain 
analysis  mediods  in  an  area  widiin  command,  conmd,  and  cmnmunicaticxis  (C^).  Based  on  initial 
leseardi,  domain  analysis  is  not  yet  a  stable  field,  and  t^ipears  to  be  evolving  toward  new 
methods  being  developed  for  sy^ms  analysis.  Object-mriented  methods  appear  the  most  popular 
at  this  time. 

Domain  aiudysis  has  bem  idmitifted  as  a  key  technology  in  enabling  systematic  reuse. 
De^te  its  original  pnxnise,  domain  analysis  has  encountered  sevoal  problems  diat  have 
prevented  its  wide  adaption  by  existing  systems  devek^iers.  The  principal  technical  proUems 
associated  with  performing  dmnain  analyses  are  die  lack  of  standards  tool  support  The 
primary  noniedmical  barrims  to  performing  a  domain  analysis  are  **stovei»ped**  systems 
devdt^ment  and  security  restrictions. 

Based  on  our  researdi,  we  conclude  that  ri  die  ^sent  time,  domain  analysis  can  be  used  to 
support  systematic  mise  widiin  Navy  in  narrow  domains  that  have  sponsors  cmnmitted  to 

rmise.  Ihim  is  little  si^iport  evident  for  systematic  reuse  crossing  sponsor  boundaries  in  die 
Navy  dcmiain  mccept  for  occasional  c^ipmtunistic  reuse.  The  lack  of  widespread  sumort  for 

tystematic  reuse  will  make  die  successfiil  application  of  dcmiain  analysis  duou^iout  (y  unlikely 
InthenearAiture. 

This  task  will  continue  research  in  domain  analysis  and  b^in  investigating  methods  used  in 
die  imi^mentation  phase  of  domain  engineering.  The  goal  of  this  next  [Aiase  is  to  imidement  an 
object-oriented  dmnain  analysis  mediod  linked  to  a  “software  architecture”  cipdile  of  suppcHt- 
iqgC^ 

OVERVIEW 

This  report  is  die  third  in  a  series  of  reports  describing  die  applicatimi  of  several  popular 
dcmiain  analysis  methods  to  the  domain.  Since  is  a  broad  clomain  encompassing  many 

different  fie^,  only  a  subset  of  was  analyzed.  This  subset  was  die  “sub^main”  of 
messa^  processing.  Domain  analysis  is  die  systematic  repiesrotation  of  information  about  a 
particular  apfdteation  domain  widi  die  aim  of  reusing  diat  informaticm  across  multiple  ippltea- 
tions  widiin  that  dcmuun.  One  purpose  of  diis  report  is  to  provide  feedback  and  lessons  learned 
on  ourip(4ic8tion  of  modern  domain  analysis  methods.  Perhaps  a  mcve  irnportam  goal  of  this 
tqxxt  is  to  suggest  directions  for  future  w^  to  improve  upon  current  domain  analysis  mediods. 

1  J.1  Dmiafo  Anatysis  Badkground 

Domain  anatysis  is  currently  viewed  as  a  key  ingredient  in  DoD’s  software  technology 
strategy  to  encourage  die  systematic  reuse  of  die  tremendous  amount  of  software  and  related 
‘hssets”  diat  D(d>  produces  each  year.  Aldiough  domain  analysis  is  recognized  as  essential  to  the 
success  of  tystenu^  reuse,  it  is  not  the  only  k^  factor.  As  die  methodology  of  domain  analysis 
matures,  it  is  increasingly  evidem  diat  other  nontechnical  factors  are  also  essential  to  the  success 
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of  syitematic  leiue  wiihin  DoD.  These  fscttm  will  be  discussed  in  diis  report  whm  die  fsctors 
have  had  substaittiai  impact  on  our  plication  of  domain  analysis. 

The  mneiging  view  is  diat  dieie  are  few  incentives  and  effective  mechanisms  to  achieve  any 
broad  level  of  software  mise  within  the  entire  DoD.  The  main  DoD  reuse  develqiment  effort  is 
qionsoted  by  die  Cmporate  Information  Management  (CIM)  program  widiin  die  Defmise 
Information  Systmns  Agency  (DIS A).  The  CIM  program  is  currently  attraipting  to  develop 
some  uniformity  among  die  myriad  ^  independently  developed  uiformaticm  systems  across  die 
services.  The  CIM  effmt  funds  the  Defense  Software  Reposhmy  System  (DSRS)  reuse  library. 
At  diis  time,  however,  diere  is  no  requirement  across  DoD  to  adt^  the  CIM  standards  and  use 
dieir  reuse  library.  Thus,  the  success  of  die  CIM  effort  is  not  yet  determiiied. 

The  Advanced  Research  Projects  Agency  (ARPA),  primarily  through  die  Software  Technol¬ 
ogy  for  Adiqitidde  Reliable  Systems  (STARS)  and  Domain  Specific  Software  Architectures 
(DSSA)  programs,  provides  the  main  research  thrust  for  domain  analysis  and  reuse  technology. 

The  Air  Fmce  has  two  programs  in  reuse.  The  Central  Archive  for  Reusable  Defense 
Software  (CARDS)  and  die  Portable  Reusable  Intended  Software  Modules  (PRISM)  programs 
are  managed  by  die  Electnmic  Systems  Cmnmand.  The  Army  is  sponsoring  imise  dno^  its 
Common  Ada  Strfkware  System  (CASS)  mid  Reusabte  Ada  Packages  for  Information  Systems 
Development  (RAPID)  programs.  The  success  or  failure  of  diese  effints  will  likely  detormine  the 
future  of  systematic  software  imise  within  the  DdD.  Currently,  die  future  of  diese  systmnatic 
reuse  and  dcmiain  analysis  efforts  is  increasin^y  cloutfy  given  the  level  of  funding  for  these 
efforts  and  die  constriction  of  die  DoD  budget 

StiU,  domain  analysis  is  beginning  a  maturation  process  and  does  offer  the  prospect  of 
providing  badly  needed  structure  to  die  current  chaotic  software  development  processes  evident 
duou^iout  DoD.  This  report  win  describe,  in  modest  detail,  die  lessons  learned  fmn  our 
q^dication  of  several  domain  andysis  and  engineering  methods. 

1,22  Domain  Analyab  Mdhoda 

The  STARS  Reuse  Ubraiy  Process  Model  (RU^  and  die  Software  Engineming  Institute’s 
(SEI)  Feature-Oriented  Domain  Analysis  (FODA)  [Coiien,  et  al.,  1990]  method  were  the 
orig^  two  mediods  used  to  analyze  the  C^  subdomain  of  message  processing.  At  the  time  our 
reseaidi  began,  these  two  iqiproaclies  were  the  best  known.  TWo  other  domain  analysis  tasks  also 
affected  the  results  of  diis  repmt  They  are  the  Dtd^’s  Corporate  InfOTmation  Managemmit  (CIM) 
domain  analysis  task  [Sc^Ibch,  1993],  mid  the  ARPA  DSSA  cmnmand  and  control  (C^)  task 
{Bimin,  et  al.,  1993].  Bodi  of  diese  tasks  produced  object-oriented  domain  analysis  methods 
based  on  existing  object-oriented  mediods  traditimudly  used  for  systems  analysis  and  design. 
Since  these  two  domain  analysis  tasks  are  of  a  mtne  recent  vintage  than  RLPM  and  FODA,  it  is 
wofdiudiile  to  compere  die  dder  and  newer  methods  to  establish  the  general  direction  of 
evolution  in  domain  analysis  mediods.  Our  examination  and  use  of  porticxis  of  these  four 
medio^  piDvkIe  the  basis  for  diis  report 

Readme  are  directed  to  earlier  repmts  [Rotter,  etal.,  1992, 1993],  uhich  describe  the 
application  of  diese  methods  in  more  detail.  The  main  aim  of  this  report  will  be  to  identify 
deficiencies  in  die  m^iods  used  and  dim,  later  in  die  report,  to  propose  solutions  to  those 
deficiencies.  There  will  be  relatively  little  expositimi  in  this  rep^  about  the  specific  models 
developed;  radim  the  focus  is  on  problmns  associated  with  the  development  of  domain  analysis 
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products,  models,  and  taxonomies,  alcmg  with  recommcnrtrnions  on  how  these  products  and 
processes  nuy  be  iiD|xoved. 

This  lepoit  also  distbiguishes  between  descriptive  models,  which  describe  infonnation  about  die 
HMce  or  domain  of  inteiest,  and  prescriptive  models,  which  focus  on  “solution*’  space 
or  oonqwier  science  related  aspects  diat  are  required  to  imfriement  a  system  in  die  dmnain.  In 
bodi  cases,  we  describe  how  our  analysis  relat^  to  die  aftHernemimied  domain  analysis  meth- 

•  ods,  the  problems  we  encountered,  and  recommendations  for  improving  the  mediods. 

^  The  orgnizadon  of  diis  iqx>it  is  described  in  the  aext  section.  This  (xganization  is  based  cm  die 

ftct  diat  domain  mialysis  experts  usually  make  the  separation  of  “what”  is  performed  from 
“how**  it  is  performed.  Scmie  experts  have  restricted  domain  analysis  to  only  the  “what”  or  prob¬ 
lem  definition  phase  of  die  analysis.  The  “how”  (x  implemrotatimi  issues  are  usually  deferred  to 
die  later  “dmnain  engineeririg”  phase.  Domain  rogineering  is  also  sometimes  used  to  describe 
die  entire  process  fixmi  problem  definition  to  solution  imfdementatitm.  To  avoid  confusion 
Hoarding  die  definition  of  domain  analysis  and  engineering,  we  will  adopt  the  term  “descrqitive 
phase”  to  describe  products  and  processes  associated  widi  the  problem  definition  and  analysis 
^lase  of  domain  analysts:  the  term  “prescriptive  phase”  applies  to  processes  and  products 
associated  widi  die  implementation  fhase,  in  vriiich  reusable  componrots  are  developed. 

13  DOCUMENT  ORGANIZATION 

This  documrot  contains  five  sections,  including  diis  introductory  section.  Section  2.0 
pceaertts  lessons  learned  duriitg  the  descr^itive  phase  of  our  domain  analysis.  Typically,  the  first 
modds  developed  during  a  domain  analyris  are  descriptive.  Descriptive  models  provi^ 
representations  of  information  about  the  dmnain  of  interest,  in  our  case  message  processing,  and 
concentrate  on  identifying  iriiat  functions  die  systems  in  die  domain  are  required  to  poform. 
These  descriptive  models  are  used  mainly  to  provide  structure  to  the  dmnain  and  mganize  the 
domain  to  ktaitify  commonalify  among  systems  widiin  the  dmnain.  Three  classes  of  descriptive 
modds  me  discus^  separately:  functional,  dynamic,  and  object.  The  sectim  is  furdier  divided 
into  subsections  concerned  widi  dmnain  analysis  products  and  subsections  associated  with 
processes  and  procedures.  There  are  also  subsecttons  providing  recommmidations  for  improving 
die  andysh  prothicts  and  processes. 

Section  3.0  is  organized  in  die  same  manner  as  section  2.0,  but  covers  prescriptive  or 
imideiiientatkxi  products  and  processes.  The  prescriptive  models  are  split  into  two  classes: 
sc^ware  architectures  and  object-oriented  designs. 

•  Section  4.0  deals  widi  the  tool  requiremmits  of  domain  analysis  and  engineering.  Current 
tod  support  is  discussed  along  widi  tools  to  suppcnt  die  descriptive  and  prescriptive  (bases.  In 

•  addition,  tool  requirements  to  develop  ^sterns  are  also  briefly  discussed.  Normally,  iqpplicaticxi 
generttion  or  system  composition  are  not  ctxisidered  part  of  ^main  analysis  and  ^main 
engineefing.  However,  one  substantial  barrier  to  reuse  adoption  in  general  and  domain  analysis 
hi  particular  is  die  lack  of  tools  to  endile  the  deveiopmoit  of  systems  using  the  products  of 
domain  analysis  and  engineering.  Therefore,  we  have  also  included  requirements  fcxr  this  class  of 
tods. 

Section  5.0  provides  conclusions  on  die  status  of  current  domain  analysis  ajpioaches  and 
dicusses  recommnidations  for  inqxoving  domain  analysis  methods. 
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2.0  DESCRIPTIVE  PHASE—DOMAIN  ANALYSIS 


The  first  i^iase  in  most  domain  analysis  methods  is  a  descriptive  [diase.  This  i^iase  deter¬ 
mines  die  bomxiary  of  die  domain  and  characterizes  die  impcntant  elements  in  the  domain. 

RLPM  accomplish^  this  goal  widi  the  (tevelopn^nt  of  a  classificadon  scheme  and  a  taxonomy 

used  to  ocganize  die  domain.  This  approach  is  heavily  based  on  the  principles  of  library  science 

and  is  geared  toward  a  reuse  effort  with  a  large  library-like  repository  of  software  and  software- 

related  conqxments.  In  this  approach,  domain  analysis  is  used  to  suf^xxt  the  oiganizatimi  of  ■ 

components  and  their  retrieval.  Because  RLPM  begins  widi  an  examination  of  existing  systems, 

it  alro  contains  some  elemoits  of  the  prescriptive  (Aiase.  The  classificaticm  and  taxmKimy  factors  * 

in  RLPM  need  not  be  (xily  problem  specific.  Many  components  will  be  classified  based  on  their 

implementatitxi  characteristics. 

The  CIM  analysis  method  (based  on  Coad  and  Younkm’s  object-miented  analysis)  [Coad  & 

Youidmi,  1991],  tlte  DSSA  aiudysis  method  (based  on  Rumbaugh’s  object-oriented  analysis 

method),  and  diie  FODA  mediod  do  make  the  distinctimi  between  descriptive  and  prescriptive 
phases.  Based  on  our  examinaticm  of  the  methods,  we  believe  tiiat  FODA  and  the  DSSA  domain 
analysis  methods  focus  more  on  products  tfian  process,  nhile  RLPM  and  the  CTM  method  focus 
principally  uprni  tiie  domain  analysis  process.  All  methods,  however,  describe  both  processes 
and  products  and  (mly  the  relative  emi^iasis  differs. 

2.1  DOMAIN  ANALYSIS  PRODUCTS 

We  have  split  the  products  of  tiie  descriptive  phase  into  three  groups:  functional  models, 
dytuunic  models,  and  object  models.  We  selected  tiiis  division  because  tiie  distinction  between 
functions,  cmitrol,  and  data  is  made  in  all  of  these  methods.  Methods  tiiat  emitiiasize  fimctions  or 
processing  use  functimial  models  most  heavily.  Oi  the  other  hand,  object-oriented  metiiods 
focus  first  (XI  the  data,  data  structures,  and  relationships  between  data  structures.  Dividing  the 
products  into  the  three  groups  allowed  a  better  comparison  betwemi  the  methods. 

Of  tiie  methods  explored,  (xily  the  RLPM  with  its  bottom-up  approach  did  not  propose 
specific  descriptive  models.  The  primary  form  of  oiganizati(xi  proposed  by  RLPM  was  based  (Xi 
tte  classificati(xi  scheme  ctxitain^  in  tiie  domain  taxcxiomy.  This  was  a  drawback  to  the  RLPM. 
hi  our  estimation,  a  taxonomy  provides  insufficient  structure  to  provide  a  framework  for  reuse. 

While  it  certainly  supports  a  reuse  library,  die  tax(xiomy  does  not  provide  enough  information  to 

determine  how  components  can  and  should  be  connect^  to  form  woridng  programs.  Linkages 

and  functitxial  connections  witiiin  the  domain  and  between  the  domain  of  interest  are  also 

required  and  need  to  be  captured  in  the  domain  analysis.  While  RLPM  mentitxis  constructing 

such  models,  it  does  not  specify  a  methodology  for  descriptive  models.  • 

The  remaining  methods  used  a  variety  of  models.  The  actual  models  used  in  tiie  domain 
analysis  were  most  closely  tied  to  FODA.  We  will  discuss  tiie  mcxlels  within  the  tiiree  groups 
separately  since  different  methods  were  mcxe  effective  in  different  areas. 

2.1.1  Fonctimnl  Models 

Functional  models  are  used  to  describe  the  behavicx  of  systems  within  a  domain.  This 
descripticxi  is  primarily  from  a  uso'  perspective.  Our  use  of  functional  models  coincided  roughly 
with  FODA.  R)DA  uses  two  sets  of  descriptive  models,  context  and  domain  models,  and  one  set 
of  prescriptive  models,  architecture  models. 
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FCX>A  CQittext  models  consist  of  a  context  diagram  and  a  structure  diagram.  The  ctxitext 
dii^ram  is  essential  in  bounding  the  draudn  and  is  essentially  the  same  diagram  as  die  Youiden, 
Constantine  Data  Flow  Diagram’s  context  model  It  describes  extonal  interfaces  to  die  domain 
of  iraeresL  This  diagram  was  quite  useful  in  die  dranain  because  it  allowed  the  separation  d 

fhxn  the  communications  dranain.  The  message  processing  subdomain  of  wm  ctxitained 
widdn  die  subdranain.  These  context  models  i^ow  fw  a  clear  repiesentadtxi  and  allow  die 
assignmcmt  of  fiincdrais  to  domains.  In  general  the  context  nuxiel  was  satisfactory  and  worked 

•  weU  in  die  message  processing  domain. 

The  second  FODA  craitext  model  was  die  structure  diagram.  The  purpose  of  diis  diagram  is 

^  to  disfdi^  other  domains  of  interest  This  chart  proved  to  be  somewhat  difficult  to  interpret 

However,  die  idea  of  intorehtting  domains  is  crucial  to  domain  analysis.  A  tyjncal  applica¬ 
tion  will  deal  with  databases,  user  interfaces,  ir^t/ouqxit  devices,  and  a  variety  of  langiu^ 
and  operating  systems.  Each  of  diese  areas  is  itself  a  domain.  The  interfaces  and  interactirais 
betw^  diese  domains  is  one  of  the  piinciide  strftwme  development  problems  faced  today.  We 
selected  an  ad  hoc  method  based  on  the  Schlaa-NfeUor  object-oriented  analysis  method  to 
rqjRsent  the  supprating  domains  for  C^.  The  area  of  describing  domain  interactions  is  one  in 
which  iKxie  of  the  methods  available  today  is  satisfactory. 

F(X)A  provides  the  feature  model  to  show  user-visiUe  characteristics  and  describe  system 
varialnlity  from  a  user  perspective.  We  did  not  use  diis  model  primarily  because  die  feai^ 
model  did  not  appear  to  sci^  fm  die  message  processing  subdomain.  Given  die  variety  of 
message  processing  ^iplications,  craistructing  a  useful  feature  model  would  be  a  large  undotak- 
ing.  hist^  we  craistructed  a  RIJPM  taxonomy  to  characterize  the  possible  variability.  The 
taxonrany  approach  appeared  bettor  able  to  scale  up  to  be  useful  in  moderate  to  large  domains. 

The  features  model  appeared  most  usefid  In  stdile  domains.  Unfntunately,  is  stable  in 
8<»ne  subdomains,  such  as  some  parts  of  message  processing,  but  volatile  in  others,  such  as  user 
interfece.  hi  a  volatile  domain  with  many  differoit  components  available  and  litde  standardiza¬ 
tion,  die  feature  model  is  likely  to  rapidly  become  enormous  as  die  domain  evolves. 

We  performed  additional  functiraial  modeling  using  a  data  flow  tqipioach  We  used  die 
decomposititm  femure  of  the  data  flow  method  to  [xoduce  a  hierarchical  decomposition  of 
and  message  processing.  This  tqiproach  loit  itself  to  automatirai  using  a  CASE  tool  sudi  as 
Software  dnou^  Pictures.  UnfcMtunately,  this  aj^xoach  also  lacked  a  rigorous  foundatirai, 
particularly  in  precisely  defining  the  int^aces  between  processes  in  dre  data  flow  diagrams. 

For  fiinctional  modeling,  the  DSS  A  domain  model  and  die  CIM  domain  model  use  the 

•  process  modeling  technique  hitegrated  Computer  Aided  Manufacturing  (ICAM)  Definition 
(IDEF),  devehqied  by  ScfTbch.  DSSA  used  IDEF  for  fimctiraial  modeling  while  CIM  used 

«  IDEF  to  model  the  domain  analysis  process.  IDEF  models  have  been  primarily  used  to  model 

business  (xactices  and  somewhat  less  often  to  model  software  processes  in  a  manner  similar  to 
data  fknv  modeling.  IDEF  has  the  advantage  of  being  anrenable  to  automation  and  can  be 
rigtnous.  The  principle  problem  we  idoitified  widi  IDEF  is  in  comparing  the  results  of  die 
DSSA  IDEF  models  to  other  models.  The  IDEF  Context  (top-level)  model  does  not  ictentify 
external  domains,  and  IDEF  does  not  have  any  concept  of  domain  partitioning.  It  aims  to  specify 
t^iat  process  needs  to  be  performed.  The  allocatirai  processes  and  data  (objects)  to  domains  is 
not  p^onned.  In  general  if  an  IDEF  process  is  moiticxied,  it  is  in  die  domain  of  interest, 
hifonnation  and  data  coming  into  die  domain  is  not  classified  or  categorized  by  die  domain  that 
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imtthe  informatioii.  Similatiy,  infonnation  leaving  the  dcMiiain  is  not  sentto  anottierdcHnain; 
ratfier  die  datt  aie  just  sent  out  to  another  process.  This  lack  of  a  doniain  orientation  niakes  it 
difficult  to  rectMnmend  fiuictional  modeling  in  domain  analysis,  however  popular  it 

may  be  for  business  process  modeling. 

Our  discussion  of  die  CIM  use  of  IDEF  to  model  the  domain  analysis  process  is  d^erred  to 
die  section  on  process  modeling,  aldunigh  we  can  state  here  that  the  use  of  IDEF  to  model  the 
domidn  analysis  process  ai^iears  more  effective  than  its  use  in  functimial  modeling.  ^ 

2.U  Dynaiolc  Modds 

» 

Dynamic  models  describe  die  bdiavior,  control,  or  tenqxnral  sequence  of  activities  oS  a 
system.  The  use  of  these  dynamic  bdiavior-describing  models  varies  considerably  between  the 
mediods.  Of  the  mediods  studied,  die  DSS  A  domain  model  for  had  the  most  detailed 

^namic  model.  The  DSSA  <tynWc  model  was  developed  using  the  Requirements  Driven 
Design  -100  (RDD-100)  tool  to  present  the  dynamic  behavior  of  a  typical  system.  Discussing 

diis  tool  is  beyond  die  scope  of  this  report,  but  die  tool  seemed  to  provide  sufficient  ciqiability  to 
model  die  flow  of  control  of  a  system.  Unfortunately,  there  are  no  standard  re{vesentations  for 
dynamk  models.  FODA  used  die  product  State-Mate  to  produce  finite  state-machine  diagrams 
rqjtesentatkxi  of  objects  within  the  domain  of  interest  ITie  finite  state-machine  represoitation  is 
used  in  odier  analysis  methods  also,  notably  die  CIM  dranain  analysis  and  the  Schlaer-MeUor 
Object-Oriented  Analysis  technique.  Generally,  dre  finite  state-machine  representation  seems 
preferred  1^  the  object-oriented  methods. 

bi  the  message  processing  domaiit  die  bdiavior,  control,  and  sequmicing  of  activities  runs 
die  gamut  from  tot^y  prescribed  to  totally  arbitrary.  In  an  embedded  message  processor,  the 
sequence  of  function  ct£us  is  typically  fixed  for  die  sy^em,  ahile  in  a  user-oriented  text  message 
edhing  ^stem,  die  user  decidre  die  sequence  of  activities  called.  Because  die  processing 
sequmice  is  quite  variable  across  message  processing  systems,  our  iqipioach  was  to  create  a 
s^araie  **executive”  process  that  handled  die  centred  and  sequencing  of  die  oth^  functions.  The 
FODA  method  seemed  to  be  die  method  closest  to  die  one  employed  in  our  analysis  since  it  also 
reemnmended  setting  up  executives  to  handle  sysrem  control  This  involved  isolating  the  control 
firmn  die  functions  in  die  message  processing  domain.  This  was  done  since  die  dynamic  or 
control  bdiavior  of  the  message  processing  domain  was  die  most  volatile  portion  oS  the  message 
procesur^  domain.  Since  most  portitxis  of  messi^e  {xocessing  are  fairly  stable,  we  performed 
die  teast  modeling  in  dre  control  area,  preferring  to  expoxl  our  effort  in  characterizing  the  othm- 
more  staUe  parts  of  the  domaiiL 

2.13  Object  Models  * 

Object  models  provide  die  biggest  discrepancy  betweoi  the  older  and  newer  models.  There  is  •' 

little  doubt  diat  die  older  domain  analysis  metlKxls  have  a  heavy  emj^asis  on  functional  models 
and  the  tfynamic  bdiavior  of  die  systems.  The  object  models  produced  using  the  older  methods 
were  largely  geared  toward  datable  develoixnent  and  used  entity-reladmiship  moctels  or  some 
variation  of  the  mtity-relationship  mottel. 

Originally,  FODA  used  die  endty-relationship  model  to  describe  objects.  Recendy,  however, 

Shdom  Cdi^  one  of  die  principal  develc^rs  (tf  the  FODA  mediod,  began  expmimaiting  with 
more  object-orimited  representations.  Notably,  he  used  a  tool  called  001,  developed  by  Hamiltcxi 
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Dschncriogies,  to  rqveseitt  die  objects  in  his  examples.  In  our  domain  analysis,  we  have  also  used 
001  to  perform  object  modeling.  It  provides  a  good  way  to  model  objects  that  are  either  pan  of 
another  object  ( a  ‘lias  a**  reladon^p )  or  (dijects  that  are  specialized  forms  ( an  “is  a“  relation* 
ship )  of  odier  objects.  The  001  tool  is  a  powerful  data  modeling,  stroctuied  programming,  code 
gmeretion  tool  primarily  designed  to  mppon  application  generation.  Thus,  001  has  a  place  as  a 
tod  siqiporting  reuse,  but  is  somewhat  misused  whoi  ap(died  to  domain  analysis  and  object 
model^. 

The  newer  domain  analysis  mediods  use  object  models  lifted  from  die  latest  diject-orioited 
analysis  techniques.  QM  pn^toses  using  Coad*  Youiden  Object-Oriented  Analysis  diagrams, 
idiile  DSS A  uses  the  Rumbaugh  Object-Oriented  Analysis  method  and  diagrams.  These 
methods  have  the  benefit  diat  popular  CASE  tools,  such  as  CADRE’S  Ibamworic,  IDE’s 
Software  diiough  Pictures  (StP),  and  Rati<xial’s  ROSE  sui^n  the  producdcxi  of  such  object-ori¬ 
ented  diagrams,  hi  Teamwoik  and  StP,  these  object  diagrams  can  be  linked  to  die  actual  code 
in^dementing  die  object  This  supports  a  ti^t  integradcxi  of  die  domain  model  produced  by  the 
domain  analysis  and  the  software  imidementatirai.  This  integration  offers  a  soluticxi  to  one  of  die 
primary  technical  problems  in  domain  analysis,  namely,  how  to  link  die  problem  space  analysis 
models  to  die  stdution  space  inqilementation  models.  As  our  own  experience  widi  these 
object-oriented  mediods  is  quite  limited,  we  will  not  discuss  the  similarities  and  differences 
between  die  various  object-oriented  mediods  availrfile  today.  Evaluation  of  diese  mediods  will, 
however,  be  performed  later  in  this  task. 

So  fv,  we  have  not  inqdemented  object  models  using  an  object-oriented  analysis  mediod. 
lUs  will  be  a  natural  next  step,  given  the  obvious  trend  toward  object-oriented  analysis,  design, 
and  programming.  We  have  also  not  discussed  the  drawbacks  in  using  object-oriented  analysis 
mediods  to  perform  a  domain  analysis.  The  chief  drawback  in  using  current  object-oriented 
mediods  for  domain  analysis  is  diat  these  mediods  were  designed  to  support  systems  analysis. 
The  goals  of  systems  analysis  are  to  support  die  design  and  development  of  a  system.  Th^ 
medrods  are  not  designed  to  model  variability;  in  fact,  they  are  intended  to  produce  an  unamlng- 
uous  and,  hence,  nonvaiiable  result.  These  m^hods  typically  drive  die  analysis  toward  a  single 
or  at  least  limited  solution  and  implemoitation,  radier  dian  to  characterize  dill  the  possible 
solutions  to  die  problem. 

hi  smne  soise,  the  shift  to  object-oriented  mediods  indicates  that  the  field  of  domain  analysis 
is  becking  off  fiom  attempting  to  describe  all  possible  variatimis  in  the  problem  and  solution 
domains,  and,  instead,  restricting  both  die  problem  and  solutimi  space  to  a  small  manageable 
number  of  alternatives.  This  restriction  is  definitely  required  in  a  field  such  as  C^.  The  variatirai 
in  function,  behavior,  and  objects  in  existing  systems  alone  is  staggering,  and  attenqiting  to 
classify  all  the  systems  in  use  today  would  be  a  massive  undertaking.  Clearly,  what  is  needed  is 
to  restrict  the  acopt  of  functirais,  bdiavior,  and  (Ejects  right  fiom  die  start  of  die  domain 
analysis.  This  restricts  die  variability  diat  can  be  described,  but  (^ers  the  hc^  diat  the  domain 
can  be  organized  undor  a  single  or  small  number  of  domain  models.  The  goal  of  these  models  is 
to  adequately  describe  most  systems  and  to  be  used  as  die  standard  for  the  enhancement  of 
existing  systems  and  the  develt^ment  of  new  systems.  These  models  would  provide  a  basis  to 
reengineer  all  existing  systems  not  following  the  standardized  domain  modete. 
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2J  IMPROVING  DOMAIN  ANALYSIS  PRODUCTS 


There  are  five  primaiy  areas  requiring  improvement  in  domain  analysis.  They  are: 

Standaids 

Representations 

Tools 

Object*oriented  methods 
Definitimis  and  goals  of  domain  analysis 

The  lack  of  standards  for  domain  analysis  jnoducts  remains  a  serious  impedirnem  to  the 
adc^on  and  use  of  any  of  the  cturent  domain  analysis  methods.  Naturally,  the  lack  of  standards 
is  due  to  the  wide  variety  of  competing  methods  all  using  different,  and  incompatible,  represen¬ 
tations.  Until  adequate  representatitxis  are  developed,  it  is  likely  that  little  standardization  will  be 
possible. 

Hie  key  technical  area  facing  domain  analysis  is  to  provide  an  adequate  representadtm  of 
domain  information.  An  adequate  representation  must  provide  a  precise,  unambiguous  descrip¬ 
tion  of  die  problem  space,  c^iable,  ultimately,  of  generating  or  composing  systems  or  subsys¬ 
tems.  At  this  ptdnt,  a^uate  representations  only  exist  in  narrow  service  domains,  such  as  the 
relational  database  dointdn  and  the  user  interface  doinain. 

hi  general  apfdicaticm  domains,  however,  die  dioice  of  tools  usually  determines  the  represen- 
tadon.  That  is.  if  a  CASE  tool  is  available,  die  domain  analysis  is  performed  using  die  CASE 
diagrams.  The  deveiq;mient  and  maturadmi  of  die  domain  analysis  methods  has  been  signifi¬ 
cantly  slowed  by  die  lack  of  tools  specifically  designed  for  domain  analysis.  Tools  designed  to 
supp^  domain  analysis  are  needed.  These  tool  lequlrements  are  discussed  more  My  in 
section  AO. 

Object-oriented  methods  offer  the  possibility  of  supporting  the  key  requirements  of  domain 
analysis.  Currem  object-ortoited  metlmds  provide  a  precise  representatimi  of  die  problem  space 
and  ‘‘map**  in  a  straightforward  way  tr  *he  solutimi  space.  There  are  currently  many  object- 
oriented  methods  in  use  today.  Since  ^^ey  are  much  more  widely  used  than  donuun  analysis 
mediods,  die  number  of  pr^ar  methods  in  wide  usage  should  begin  to  reduce  to  a  few  meth¬ 
ods,  supported  by  the  most  pqnilar  CASE  tools.  An  effective  domain  analysis  method  should 
arise  fifom  at  least  one  of  di^  object-orioited  mediods.  This  object-oriented  mediod  will  be 
supported  1^  CASE  tools  and,  hence,  provide  an  adequate  representation  of  systems  in  the 
domain. 

For  object-miented  mediods  to  provide  a  satisfactory  solution  for  domain  analysis,  domain 
analysis  will  have  to  revise  its  own  goals  and  (tefiniticm.  Currently,  domain  analysis  attempts  to 
categorize  die  variability  of  possible  aiKl  existing  systems  in  die  domain  in  addititm  to  providing 
die  fiamewoik  and  structure  to  build  multiple  systems  within  the  domain.  If  die  definitimi  of 
domain  analysis  is  revised  to  only  providii^  the  frameworic  and  striK^ture  to  build  a  restricted 
family  of  systems  within  the  domain,  object-oriented  mediods  provide  a  nice  fit  This  change  in 
definition  restricts  the  scope  and  purpose  of  the  analysis  but  provides  a  better  means  to  in^ile- 
mnit  m  architectural  solution.  This  is  not  to  say  diat  categorization  of  die  variability  of  systems 
cannot  be  done;  ladier,  once  die  variety  of  systems  is  described,  restrictions  mi  diat  varied  are 
soon  made  to  limit  die  8cq;)e  of  possible  systems  that  can  be  imfdemoited.  The  domain  nuxlel 
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itni  refinaeitts  a  restricted  subset  of  systems  with  tile  goal  to  provkle  a  6amew(Mrk  for  building 
qfstems  widun  tfiat  restricted  subset  Aldiough  not  explicitly  stated,  suppmt  for  diis  notion  of 
restricted  reuse  is  present  even  in  die  eariier  mediods  [Prieto-Diaz,  1991].  In  Prieto-Diaz’s 
mediod,  die  ^tems  are  categorized  and  cataloged,  dim  a  **shrinkage”  occurs.  In  this  shrinkage, 
qrstems  and  ctmqKxients  are  evaluated  for  commonality  and  extraneous  or  aberrant  con^xxients 
or  systems  are  discarded.  The  result  is  a  rethiced  set  of  components,  which  are  dien  reengineered 
to  a  common  but  rntne  restrictive  framework. 

To  summarize,  our  suggestions  for  improving  domain  analysis  processes  are  consistent  with 
recent  trends  in  domain  analysis  research.  First  adoi^  currmtly  pr^ular  object-oriented  analysis 
mediods.  Switch  from  a  predominately  functicmal  view  of  systems  to  an  object-cnimited  view. 
Use  CASE  tools  imidemmting  object-oriented  mediods  to  represent  die  domain  analysis  rreults. 
The  dranain  model  resulting  from  diis  object-oriented  approach  will  no  Iraiger  focus  (xi  die 
varialnlity  of  the  dmnain.  Instead,  the  domain  model  will  provide  a  restricted  framework  fmr  die 
domain,  based  on  the  objects  in  the  domairt  As  object-oriented  mediods  stabilize,  standards  will 
evdve.  Voder  diis  scenario,  domain  analysis  will  merge  widi  object-oriented  analysis.  In  some 
ways,  this  merger  is  abea^  beginning.  The  enqdiasis  in  object-orioited  methods  has  been 
steadily  moving  toward  the  creatirai  (tf  reusable  class  libraries.  Object-oriented  analysis  then 
providM  die  framewmk  for  connecting  these  reusable  classes.  This  framework  satisfies  die  main 
requirement  of  die  restricted  view  of  domain  analysis. 

In  die  research  performed  so  feu*  on  diis  task,  we  would  rectmimend  using  die  Schlaar-MellOT 
object-oriented  analysis  mediod  [Schlaer  A  Mellor,  1989]  to  perform  a  domain  analysis.  The 

primary  reasons  far  this  recommendaticm  are  twofold.  Fim,  die  Schlaer-Mellor  mediod  provides 
the  strongest  domain  orientation  of  all  the  current  object-oriented  mediods.  hi  fact  they  devote 
an  entire  duqiter  their  bock  "Object  Lifccyctes,  Modeling  die  World  in  States'*  [Schlaer  A 

Mellor,  1992]  to  a  discussicxi  of  domains.  Their  notion  of  a  domain  is  consistent  widi  domain 
analysii  and  diey  propose  die  novel  concq;it  of  "sctftwaie  bridges”  to  ccmnect  ^mains. 

Second,  die  Schlaer-Mellor  mediod  is  also  amcmg  the  most  detailed  and  complete,  including 
bodi  process  and  products.  The  mediod  also  includes  tight  ccxinections  between  the  analysis 
phase  and  rmisaUe  conqxxient  inqilemoitation  using  their  recursive  design  technique.  Since  diis 
mediod  has  not  yet  been  apfdied  as  a  domain  analysis  mediod,  me  recommendation  of  this 
rqxnt  is  to  pmfonn  a  Schbter-Mellor  analysis  and  recursive  design  implementation  on  the 
message  processing  domain  (or  othm*  suitable  subdomain). 

23  DOMAIN  ANALYSIS  PROCESSES 

The  size  of  die  effort  described  in  diis  report  precluded  the  use  or  adoptim  of  any  extensive 
domain  analysis  process.  T\vo  methods,  the  RLPM  and  the  CIM  methods,  provide  detailed 
process  models  diat  iqipear  reasonable  fm  larger  scale  domain  analyses.  The  applicability  of 
these  processes  to  is  discussed  in  a  later  paragnqih.  The  FODA  method  was  primarily 

product-orimued  with  litde  process  advice. 

The  process  model  followed  in  diis  task  was  miginally  suggested  by  Prieto-Diaz  and, 
subsequ^y,  partially  included  in  die  RLPM.  His  basic  recommoidation  was  to  first  sift 
dirou{^  exiting  systems,  including  source  code  and  documentatim,  to  identify  commonality.  In 
the  messi^  processing  area,  we  were  moderately  successful,  while  in  die  area,  this  proved 
essmtially  inqxMsible.  The  fundanteiital  reasm  fm  the  failure  of  the  domain  analysis  process 
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across  was  die  “stovepqie**  nature  of  cunent  systems  development  Within  Navy  programs, 
infimniation  about  die  program  is  usually  available  to  those  working  on  die  program.  Across 
pn^nams,  however,  the  situatitxi  changes  dramatically.  In  some  cases,  the  program  sponscM* 
restricts  access  to  source  code  of  current  systems,  while  in  others,  little  documentation  is 
availaUe.  In  many  odio^  systems,  much  of  the  information  has  security  restricticms,  making  it 
difficult  to  use  in  diis  task.  The  result  was  that  die  overall  informatimi  used  to  ctxistruct  die 
domain  taxmiomy  and  models  for  were  constructed  from  more  high-level  architectural 
documents  rather  dum  actual  fielded  systems.  Thus,  the  resulting  model  remained  at  a  « 

relatively  high  level  and  represented  more  conceptual  models  for  that  are  quite  coarse¬ 
grained  in  their  covouge  C^.  These  models  lack  the  technical  detail  that  would  come  ffom 

examining  teal  fielded  systems. 

The  message  processing  models,  however,  used  more  detailed  documentation  and  existing 
unclassiffed  systems.  This  produced  a  more  detailed  taxmiomy  for  the  message  processing 
domain.  Even  widiin  the  message  processing  domain,  knowle^e  of  available  systems  was  fre¬ 
quently  limited  to  systems  organizationally  “close”  to  die  task  members.  This  niakes  it  difficult 
to  say  that  our  domain  analysis  is  representative  of  systems  duoughout  die  Navy,  much  less  die 
other  services.  Still,  at  least  (xie  of  the  key  systems  used,  die  Joint  Automated  Message  Editing 
System  (JAMES),  has  been  used  for  several  years  in  preparing  message  text  format  (MTF)  mes¬ 
sages  in  the  joint  arena. 

Unfortunately,  most  (tf  the  process  models  proposed  today  assume  an  open  organizadmud  struc¬ 
ture  widi  access  to  divnse  systems  easily  available  widiin  die  organizatitm.  For  die  fcneseeable 
future,  the  Navy,  and,  presumably,  the  other  services  do  not  operate  this  way.  Software  develop¬ 
ment  hi  die  domain  is  divided  into  many  competing  subdomains  diat  have  litde  intnest  in 
sharing  knowledge  or  resources.  Unless  there  is  a  dramatic  shift  in  the  organizadcmal  structure 
dud  devel<^  systems,  the  applicatitxi  of  any  large-scale  domain  analysis  process  seems 
unlikely  to  have  substantial  impact  on  fielded  system  developmoit  This,  of  course,  also  dims 
the  oudook  for  substantial  systematic  reuse  in  domain.  There  is  encouragement,  however, 
in  diat  at  the  spcmsor  level,  cost  is  driving  many  program  executive  officers  and  program  manag¬ 
ers  to  begin  consolidating  systems  and  eliminate  redundant  fiinctionaliQr.  The  Navy’s  shore  mid 
afloat  tactical  qxmsorship,  for  example,  already  identified  common  “core”  components  that 
can  be  used  as  building  blocla  to  currnit  and  future  tactical  systems.  This  effort  can  be  viewed 
as  a  domain  analysis  within  that  one  sponsor’s  programs. 

The  firud  area  of  concern  about  domain  analysis  processes  is  the  level  of  suf^xxt  they  offer  to 
evoludmiary  system  developmoit  Evolutionary  system  development  is  emerging  as  the  most 
pc^Milar  way  to  build  systems  in  an  era  of  rtqiid  technical  development.  The  idea  bdiind  evolu-  ^ 

tionary  developmoit  is  ttmt  technical  progress  cannot  currmitly  be  accurately  predicted  over  the 
Zfi-year  expected  lifetime  of  current  systems.  In  order  for  systems  to  adapt  m  new  technical 
developments,  the  system  develc^ment  process  must  fiequently  reevaluate  technical  require¬ 
ments  and  enhance  or  reengineer  the  system  to  operate  under  new  conditions. 

The  need  for  an  evolutimiary  development  process  has  not  really  been  recognized  in  current 
domain  arudysis  processes.  Although,  most  methods  indicate  that  producing  a  domain  model  is 
not  a  one-titiw  effort,  few  irxiicate  how  the  domain  model  is  to  evolve  over  time.  Thus,  although 
dtere  is  a  feedback  loop  in  most  processes,  relatively  little  attentitm  is  given  to  the  mechanisms 
and  processes  that  sui^rort  the  feedback  to  die  analysis  models  as  the  domain  evolves,  ^thout 
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idlofwance  to  <fynamk  evohitian  of  a  domain,  these  processes  are  rel^ated  to  stat^  unch^ 
dnni^  IMoKtanaiely.  is  not  such  a  domain. 

24  IMPROVING  IX>MAIN  ANALYSIS  PROCESSES 

Ite  (levioiis  section  and  its  discussion  of  die  proUem  areas  provides  obvious  areas  and 
mens  to  improvement.  The  biggest  hunUe  to  overeome  in  imidemnting  laige-scale  systematic 
rene  across  a  broad  dmnain  such  as  is  oiganizational  and,  hence,  process  oriented.  The 

*  cunent  oiganizational  structure  and  mediods  to  developing  systems  precludes  the  wide¬ 

spread  use  of  domain  analysis  and  raise  processes  and  products  available  today.  These  methods 
^  cn  be  effectively  used  widiin  subdcunains,  partfeulariy  domains  conticdled  by  one  ^xxisor. 

Extending  domain  analsyis  across  (Ufferait  sponsors  win  require  ccmsideiable  oignizational  and 
political  pressure  since  ny  substantial  raise  effort  wiU  divert  resources  fiom  current  devek^ 
ment  efforts. 

Improvii^  die  domain  analysis  process  to  handle  die  evoludoiary  developroem  should  not 
be  too  difficult  In  fact  if  object-oriented  mediods  omtinue  to  develr^  and  d^  analysis  and 
implementatioo  phases  me  tiglidy  cmmected,  die  evolution  of  die  dmnain  model  will  drive 
^stem  evolution  since  the  domain  model  wUl  be  used  to  generate  or  compose  die  next  evolution 
in  die  systems. 


A 
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3.0  PRESCRIPTIVE  PHASE— DOMAIN  ENGINEERING 


Die  prescriptive  phase  takes  the  products  of  the  domain  analysis  (usually  referred  to  as  die 
dmnain  model)  and  translates  at  nu^  die  model  to  a  framewmk  fiom  which  wtnking  ini(de- 
mentadcHis  can  be  imi^mented  in  a  straightforward  manner.  Die  framework  is  usually  called  a 
software  architecture.  Diis  architecture  should  contain  sufficient  detail  and  processes  for  system 
design  to  proceed  direcdy  6om  the  architecture.  Die  development  of  a  software  architecture  is 
beymid  the  traditional  scope  of  dcnnain  analysis.  Architecture  develqiment  is  typically  included 
widi  domain  analysis  in  die  broader  term  “dmnain  engmeering.” 

Diis  sectimi  briefly  describes  lessons  learned  so  far  in  performing  initial  steps  in  the 
prescriptive  ptaat  of  domain  engineering,  that  is,  developing  software  architecture  and  produc¬ 
ing  a  fimnework  for  system  design.  Die  task  reported  here  has  only  begun  to  enter  this  phase; 
hence,  few  products  and  processes  have  been  tested.  Diere  ate,  however,  some  early  results  to 
commemon. 

3.1  DOMAIN  ENGINEERING  PRODUCTS 

The  key  product  in  the  domain  engineering  i^liase  is  a  software  architecture,  smnetimes 
called  a  generic  architecture,  for  the  domain.  Compared  to  die  domain  analysis  (rfiase,  relatively 
little  research  has  been  published  on  the  ingredients  necessary  in  a  software  architecture  to 
support  domain  engineering.  From  our  brief  experience  in  developing  a  software  architecture  for 
message  processing  and  attempting  to  use  that  architecture  to  develt^  a  system  design,  we 
aheacfy  can  provide  some  feecKiack  in  this  area.  Diis  will  be  a  key  area  in  our  future  eff(»ts. 

3.1.1  Software  Architectures 

Conventicmal  software  architecture  representations  seem  to  have  standardized  on  a  diagram 
known  as  a  reference  architecture.  A  pc^mlar  reference  architecture  in  widespread  use  today  is 
die  Nati<»al  histitute  of  Standards  and  Tbchnology’s  (NIST)  ^ifdicatimi  Portability  Profile 
(AFP).  The  NIST  APP  is  displayed  in  figure  1.  Mdiin  DoD,  versions  of  this  reference  model 
have  ^rpeared  in  the  QM  technical  refemice  model 

This  architecture  describes  a  layered  set  of  services,  with  an  ai^cation  level  on  top.  The 
iq^catkxi  layer  contains  a  suf^xut  iqiplicatioiu  layer  immediately  below.  Both  of  these  layers 
w(^d  vary  depoiding  upcm  the  domain  of  interest.  The  remaining  service  layers  would 
presumably  support  multiple  domains.  The  services  are  generic  in  die  reference  model  Specific 
standards  for  dU  services  are  proposed  in  a  reference  model  standards  profile.  Die  specific 
standards  lypicaUy  include  bc^  current  standards  and  proposed  future  standards. 

hi  our  task,  we  develt^ied  a  reference  model  sui^rting  die  domain.  It  is  displayed  in 
figure  2.  This  architecture  fills  in  recommended  sui^rt  a{^licati(ms  for  message  processing  and 
adds  anodier  domain-tailored  core  service  layer  below  the  domain-tailored  services  (suppmt 
api^catimis)  layer.  In  the  bottom  layers,  diis  architecture  is  consistoit  with  die  NIST  AI^. 
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Rgiiie  1.  NIST  apfriicatiofi  p(»tability  profile  lefeiefice  model 


Rgme  2.  Command  and  control  refooice  model. 
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bi  tfiit  initial  developmoit,  several  problms  have  ataeady  surfaced.  The  purpose  of  the 
software  arehitecture  is  to  serve  as  a  bridge  between  die  results  of  the  dranain  analysis  (the 
domain  model)  and  die  ^stem  design.  In  fact,  it  i^ipeais  that  a  r^erence  architecture 
neidier.  Hrst,  there  is  no  mapfdng  bock  to  the  domain  model  and,  second,  the  refoence  architec¬ 
ture  provided  insufficient  inri^  into  how  systems  are  to  be  constructed  using  it  Certainly,  if 
one  used  components  developed  using  die  standards  prescribed  by  die  reference  model  stan¬ 
dards,  die  system  will  satisfy  the  reference  architecture.  This,  unfortunately,  does  not  prescribe 
the  ^stemdesign  very  much.  A  useful  software  ardiitecture  should  lead  to,  at  most  a  few 
possiUe  Systran  designs.  Clearfy,  more  is  required  duui  sinqdy  a  reference  architecture  to  provide 
a  ftamewofk  to  support  reuse. 

3.1J  System  Dcrign 

In  general,  most  reference  models  do  not  corttain  enough  information  to  produce  an  unam¬ 
biguous  design  (object-oriraited  not)  for  a  givrai  system.  This  is  mainly  due  to  die  lack  of 
dmsil  described  earlier  in  current  reference  models.  Also,  based  on  our  recranmraidation  to  use 
object-oriented  analysis  methods,  object-oriented  designs  (0(^)  would  be  die  obvious  choice 
to  use  in  system  design.  Unfortunately,  current  software  ardiitectures,  being  functioiudly  or 
service  oriented,  do  not  particularly  suppmt  OCX). 

IMPROVED  DOMAIN  ENGINEERING  PRODUCTS 

C)or  rnain  suggestion  for  irnptoving  software  rachitecture  is  to  add  inore  detail.  A  reference 
architecture  is  insufficient  to  provide  die  necessary  linkage  between  die  domain  model  and 
system  design.  What  is  needed  is  a  generic  system  design  widi  prmcribed  and  well-defined 
httnfeces.  The  generic  units  must  be  mipped  unambigimsly  back  to  the  dmnain  model,  eidirar 
ftmcdonaUy  or  by  objects.  When  die  dcHi^  model  changes  m  evolves,  die  generic  ^tem 
design  must  have  some  defined  way  to  change  or  add  new  design  elements  and  dieir  interfaces. 
Some  of  die  more  recem  object-orimted  analysis  and  design  mediods  are  close  to  providing  diis 
linkage,  lb  date,  die  more  ftmctionally  oriented  domain  atudysis  mediods  have  had  a  difficult 
time  maintidning  the  correspondence  between  the  dranain  m^l  and  ^stem  design.  Tools  to 
automatically  ’Trace”  dumges  in  die  domain  nuidel  dnou^  to  die  softie  architecture  are  not 
available,  ptobaUy  because  diere  are  no  emraging  standards  frar  domain  models,  for  refermce 
architectiires,  (vfrarhow  diis  traceabilify  is  to  be  adiieved. 


4.0  TOOL  REQUIREMENTS 


41  CURRENT  TOOL  SIIFFOST 

There  it  litfle  current  tool  support  geared  specifically  for  ckwnain  analysis  and  domain 
engtoeaing  beciureifae  field  it  ttiU  too  sinaM  and  immature  to  have  inuch  in  fee  way  of 
apedaliaed  took  available.  Faitunaiely,  niudi  of  the  woik  in  donudn  analysis  is  being  accom- 
piished  ttaou^  die  use  of  exisdi^  tools  developed  for  odier  purposes.  In  this  section,  we  will 
describe  in  tdbidv  fonn,  die  general  to(d  incpiireniMts  f(v  descriptive  models,  prescriptive 
modds,  and  application  genevdion.  The  toc^  are  described  only  by  genotd  ty^  and  no  specific 
products  are  proposed.  Sonie  of  diese  tools  vrere  (xiginally  qiecified  in  die  CECOM  Rqxnt 
*Tiiq;Mct  of  Domain  Analysis  on  Reuse  Mediods**  [Software  Productivity  Solutions  Inc.,  1989]. 
Mai^  of  diese  tools  are  currently  avaihdile,  althou^  diey  have  not  been  combined  into  an 
im^ated  domain  analysis  tooiaet 

42  TOOL  REQUIREMENTS  FOR  ALL  PEASES  OF  DOMAIN  ENGINEERING 

Project  management 

Software  cost  modeling 

Word  processor  and  desktt^  puUishing 

DatabiM  management  systm 

Configuration  nunagement  and  version  control 

Tkaceability 

Change  propagation 

43  TOOL  REQUIREMENTS  FOR  DESCRlPnVEMfMlELS-^MAIN  ANALYSIS 
TOOLS 


Rmctional  or  object  modeling 
Data  dictionary 

Specification  language  (grqiiiical  or  text-based) 
Chirtering/cataioging  (fSor  Frieto-Diaz) 
Knosdet^  Canute 


44  TOm.  REQUIREMENTS  FOR  PRESCRIPTIVE  MODELS— DOMAIN  DESIGN 
TOOLS 

Architecture  design 
Systems  analysis 
Reuse  libiwy 

Componem  cataloging 
Component  clasdfication 
Component  qualification 
Component  management 


15 


Simuladon 

noCotyping 

4J  TOOL  REQUIREMENTS  FOR  AFPUC  ATION  GENERATION— COMPONENT 
DEVEU^MENT 

Reuse  libiaiy 

Component  identification 
Component  developmnit 
Conqxment  tailoriiig 
Component  ttonge 
Component  retrieval 
Component  intention 
Simulation 
lYoiotyping 

System  cmiqKMition/geneiation 
Testing 

Software  develofMnmit  enviionment/CA^ 

Reveise  migineering 
Reengineering 

46  IMPROVED  TOOL  SUPPmtT 

Hie  primaiy  requirement  tor  inqsroved  tool  support  is  better  tool  integration.  Standards  such 
as  the  Portable  Common  Ibol  Environment  (PCIB),  which  provides  a  framework  and  data 
interchange  standards  for  the  exchange  of  data  between  tools,  and  Object  Linking  and  Embed’ 
<fing  (CX£),  a  Microsoft  stmidaid  frar  apfdications  to  use  othmr  iqiidications,  offer  robust  ways  to 
share  data  and  information  among  different  tools.  One  area  of  additional  work  in  this  task  will  be 
to  evaluate  tfiese  different  standards  frrr  use  in  toed  and  component  integrttion. 

Since  dmnain  analysis  as  a  field  is  small,  it  will  likely  have  to  frdlow  existing  software 
devdopment  tod  vendms  radior  dun  to  attempt  to  d^ne  a  domain  analysis  standard  for  tool 
integnakn  and  dmnain  analysis  knowtodge  representation.  Being  a  from-end  activity  in  the 
software  development  life  cycle,  domain  anal^  activities  will  most  likely  use  from  end  CASE 
tods  such  as  Teamwmk  and  Software  through  PKtutes  to  capture  and  represent  most  infotma- 
tioiL  Special-purpose  domain  audysis  tools  will  dien  be  integrated  into  die  CASE  tool  to  provide 
capabilities  uniquely  required  by  ^main  analysis. 

Many  of  die  tods  mentioned  in  die  list,  notably  reverse  engineering,  reoigineering,  knowl¬ 
edge  capture,  and  system  conqiosition  or  generation  tods,  are  still  themselves  quite  immature. 
Thus,  di^  now  provide  only  limited  siqiport  for  domain  analysis.  Furdier  develt^ment  of  these 
immature  tods  will  be  required  to  adequately  suppmt  domain  analysis.  As  diey  improve  and 
provide  adequate  rqxesentations  for  individiial  systems,  these  same  tools  can  be  used  in  domain 
anatysis  to  d^elop  die  domain  models. 
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5.0  CONCLUSIONS  AND  RECOMMENDATIONS 


Domain  analysis  is  a  young  field  that  has  not  yet  been  fully  defined  and  scoped.  The  original 
view  of  dmnain  analysis  as  a  medKxldogy  to  characterize  families  (rf  systems  within  a  domain 
and  then  to  provide  a  firamewotk  to  develop  a  wide  variety  of  systems  has  evolved.  Having  bemi 
smnewhat  oversold,  domain  oialysis  seems  unable  to  achieve  this  flexibility.  The  traid  now 
seems  to  be  toward  restricting  the  fiiamewoik  and,  thereby,  reducing  the  variety  of  systems  in  the 
domaiiL  This  permits  more  reuse  potential  and  greatly  simplifies  the  develofHnmt  of  an 
inplemNitation  firnnewoik.  The  precise  representation  of  diis  frameworic  using  a  software 
architecture  is  still  an  open  problem  that  exists  both  in  domain  analysis  and  systems  analysis. 

AldKXi^  many  of  the  technical  issues  concming  representing  domain  informatitxi  and  tool 
supptMt  still  exist,  they  can  be  solved  provided  domain  analysis  and  systems  aiudysis  receive  die 
support  necessary  to  mature.  Most  likely,  diis  maturation  will  involve  the  use  of  object-oriented 
analysis  and  design  methods  adipted  fiom  systems  analysis.  Since  systems  analysis  is  a  *1>igger” 
field  than  domain  analysis,  domain  analysis  standards  most  likely  be  developed  within  the 
context  of  systems  aiudysis. 

CXu:  recommendation  is  to  amcentrate  on  the  p(pular  object-miented  systems  analysis 
ipproaches  to  perform  domain  analysis  Among  drem,  Schlaer-MellOT  Object-Orioited  Analysis 
r^resents  a  fiMy  complete  and  detailed  approach.  It  has  been  proposed  here  at  NRaD  as  a 
“standard**  for  use  in  systems  analysis  and  design  and  should  be  effective  in  domain  analysis 
also.  The  ipplicability  of  die  Schlaer-Mellor  method  to  perform  domain  analysis  and  engineer¬ 
ing  needs  to  be  tested  and  validated.  Finally,  die  Schlaer-MeUor  method  allows  considerable 
latitude  in  die  definition  and  represmitation  of  a  software  architecture.  A  satisfactory  definition 
of  software  architecture  diat  can  be  used  to  support  the  developmmit  of  multiple  systems  widiin 
die  domain  needs  to  be  develcped  and  tested.  This  architecture  needs  to  be  compatible  widi 
modem  reference  models  and  software  architectures  such  as  the  NIST  AFP,  yet  provide  more 
detail  in  the  application  layer(s)  about  the  software  design  and  interface  specificatitxis  between 
b^rs  in  die  reference  mo^L 
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APPENDK  A.  GLOSSARY 


Abttnction:  An  idMtraction  mci^ulatBS  essential  object  characteristics  that  distinguish  it  fincxn 
dl  other  Qrpes  of  objects  nd  provides  defined  conceptual  boundaries. 

^qidkation:  A  software  program  that  provides  a  solution  to  some  type  of  user  prc^lem. 

Context:  Hie  circumMoices  <x  environment  in  niliich  a  particular  system  exists. 

Commit  Model:  A  view  of  the  problem  domain  tiiat  dejncts  the  interaction  between  ttie  dcunain 
under  study  and  the  connecting  dmnains  or  otiier  systems. 

Descrqitive  Model:  A  view  (or  multiple  views)  of  the  problem  domain  that  describes  the  entities 
in  the  proUern  domain,  tiieir  interrelatkmships,  and  key  fiinctimis  performed  in  die  proUem 
domain. 

Descriptive  Phase:  The  portion  of  die  domain  engineering  activity  that  produces  descriptive 
models. 

Dmnain:  A  fiunily  of  curiem  and  future  system  i^lkations  that  share  common  capability  and 
data. 


Dmnain  Analysis:  Hie  dmnain  migineering  activity  that  identify,  organizes,  and  rqnesents 
informatian  finmi  a  family  of  systems  (a  domidn)  based  on  the  stuffy  of  exist^  system  docu- 
ineiitation  arid  infotination  diat  can  be  learned  from  dranain  experts. 

Dmnain  Arudyst:  The  person  conducting  die  study  of  existing  system  documentation  and  acquir¬ 
ing  information  dnough  crnmnunicating  with  dmnain  experts. 

Dmnain  Eqgineeriiig:  The  activity  mcompassiitg  dmnain  analysis  and  domain  implemmitation 
resultii^  in  system  development. 

Dfxnain  Expert:  A  person  widi  expertise  in  die  dmnain  under  stuffy. 

Dmnain  Imidmnentation:  The  domain  engineering  activities  that  use  die  products  of  domain 
anafysis  to  develop  a  new  system. 

Domain  Model:  A  definition  d  the  functions,  objects,  data,  and  related  intnfaces  usually 
deidcted  gnqdticalfy. 

Dynamic  Model:  A  descrfytion  d  die  control  of  a  system,  particularly  emphasizing  die  time- 
dependem  processing  and  terrqxxral  fxdeiing  of  functions. 

Facer.  An  aq«ct  of  die  dcmiain  used  for  classification. 

Ftmctiori:  An  f^yatkm  fm  an  object  widiin  a  dfHnain. 

Ftmctiorud  Model:  A  dq[Mction  of  fiuictions,  usually  within  the  problem  domain. 
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Object:  A  thing  in  the  domain  which  is  acted  upon  and  acts  upcxt  <Mher  objects. 


Object  Models:  A  description  the  (Ejects  in  a  system  and  the  interelati(Hish4>s  betweoi 
objects. 

Prescriptive  Model:  A  view  (or  mult4>le  views)  of  the  in4>lementation  domain  that  describes  the 
oitities  in  die  implementati<xi  domain,  dieir  inteirelationships,  and  key  functions  required  to  pro¬ 
duce  an  implementation. 

Prescriptive  Phase:  Ihe  portion  of  the  domain  en^neeiing  activity  that  produces  prescriptive 
models. 

Raisable  CompcxMnt:  A  software  conqxment  (not  restricted  to  source  code)  specifically 
designed  and  implemnited  to  be  reused. 

Software  Architecture:  A  high-level  depictitxi  of  functions,  objects,  ccrntrol,  data,  and  related 
intofaces  to  support  the  implementatitxi  of  applicatimis  in  a  domain. 

Software  Reuse:  The  process  of  developing  new  software  systems  using  existing  software  com¬ 
ponents. 

Taxmiomy;  A  collection  or  group  of  domain-relevant  terms  that  provide  a  classificatimi  scheme 
for  identifying  and  describing  conqxmoits  within  die  domain. 
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APPENDIX  B.  ACRONYMS 


APP 

ARPA 

Apfdkatkxi  Portability  Profile 

A^anced  Research  Flojects  Agency 

C? 

C? 

CARDS 

CASS 

OM 

Command  and  Control 

Command,  Control,  and  Communications 

Central  Archive  for  Reusable  Defense  Software 

Common  Ada  St^are  System 

Centat  for  Informati<m  Mmiagement 

DA1»> 

DISA 

DSRS 

DSSA 

D6D 

Domain  Analysis  and  Design  Process 

Defense  Information  Systems  Agency 

Defense  Software  Rep^tory  System 

Domain  Specific  Software  Architecture 

Department  of  Defense 

¥GDA 

Feature-Oriented  Dmnain  Analysis 

ICAM 

IDEF 

Integrated  Computer  Aided  Manufacturing 

Integrated  Gunputer  Aided  Manufacturing  (ICAM)  Definition 

NIST 

National  Institute  of  Standards  and  Technology 

OLB 

OOD 

Object  Linking  and  Embedtfing 

Object-Oriented  Design 

PCTE 

PRISM 

Porutble  Common  Tool  Envinxunem 

Portid>le  ReusaUe  hitegrated  Software  Modules 

RAPID 

RDD-100 

RLFM 

Reusable  Ada  Packages  for  Infmmation  Systems  Development 
Requirements  Drivoi  Design  -  100 

Reuse  Library  Process  Model 

sm 

STARS 

StP 

Software  Engineering  histitute 

S<rftware  Technology  for  Adaptable  Reliable  Systems 

Software  Through  Pictures 
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APPENDIX  C.  DOMAIN  ANALYSIS  METHODS 


This  qipeiidix  contains  a  brief  description  of  die  domain  analysis  methods  discussed  in  diis 
iqMft  Fdr  more  detail,  the  reader  should  consult  die  leferences  on  each  mahod. 

FEATUREORIENTED  DOMAIN  ANALYSIS  (FODA) 

P(X>A  was  devek^ied  by  Shdom  Cohen  and  othms  as  part  of  Domain  Analysis  Project  at 
die  Software  Engineering  Institute.  FODA  has  three  distinct  {biases;  context  analysis,  domain 
modding,  mid  architecture  modeling.  The  context  analysis  scopes  die  domain  and  establishes 
boundaries  betweoi  the  <kHnain  and  other  domains.  The  domain  modeling  phase  constructs  a 
descr4)tion  of  die  problem  qiace  called  die  domain  model.  Lasdy,  the  architecture  (Aiase  pro¬ 
duces  a  software  architecture  sufidciendy  detaited  to  construct  applicadons.  FODA  is  primarily  a 
model-based  method  and  produces  a  variety  of  models  correspofiding  to  the  three  i^ia^.  A 
ccmqdete  description  of  these  models  is  beyond  die  scope  of  this  appoidix;  however,  diese 
models  are  predmninately  functional  models.  The  FODA  method  currendy  lists  die  following 
models. 

Context  diagram 

Structure  diagram 

Domain  terminology  dictionary 

Entity^elatkxitiiip  model 

Feature  model 

Ftmctional  model 

Object  connection  update  model 

FCX)A  is  currmtiy  being  used  in  the  Manraver  Cmtrol  subsystem  of  die  Army’s  Common 
Ada  Software  System  (CASS). 

STARS  REUSE  LIBRARY  PROCESS  MODEL  (RLPM) 

There  are  five  steps  in  die  STARS  process  model: 

Knowledge  acquisition 
Domain  definition 
Classification  and  keywords 
Ftinctiorud  models 
Dmnain  architecture 

Thme  are  two  key  fsctors  to  note  about  die  STARS  domain  analysis  process.  First,  the 
STARS  domain  analysis  is  heavily  biased  toward  (xocess.  Thoe  is  litde  exposition  (Hi  die  spe¬ 
cific  models  or  domain  representations  that  are  to  be  produced  There  is  also  litde  guidance  pro¬ 
vided  on  how  to  perform  much  of  die  process.  Second  die  STARS  process  is  a  combined  top- 
down  and  bottCHn-up  process.  The  top-down  poiti(Hi  of  die  process  is  described  mainly  in  the 
functional  models  widi  the  bottom-up  analysis  performed  in  die  classificadtHi  and  keywords 
analysis.  This  ccHntrined  rqiproach  was  unique  to  die  RLPM.  The  RLPM  is  based  (mi  Ruben 
Plieto-Diaz’s  work.  This  mediod  adtqits  many  princii^es  from  library  science  to  die  organization 
and  inqilementation  of  a  reuse  library. 
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DEFENSE  INFORMATION  SYSTEMS  AGENCY  (DISA)  CENTER  FOR 
INFORMATION  MANAGEMENT  (CIM)  DOMAIN  ANALYSIS  AND  DESIGN 
PROCESS  (DADP) 


The  domain  analysis  process  draft  document  proposes  a  fairly  complete  domain  analysis  pro¬ 
cess  via  IDEF  diagra^.  The  activities  described  in  the  DADP  roughly  parallel  the  STA^ 
RLPM.  The  description  o(  tlM  products,  however,  is  much  more  detailed  Each  of  the  models 
developed  is  illustrated  by  an  example.  The  DADP  also  proposes  using  an  object-orioited  m^- 
odrdogy.  Most  of  dieir  diagrams  are  based  on  die  Coad-Yoi^n  Object-Orioited  Analysis  dia¬ 
grams  and  mediod  but  thm  is  no  specific  requirement  in  dieir  guidelines  to  use  any  particular 
method  In  fact,  diey  reference  most  of  the  current  object-oriented  analysis  methods,  including 
Bailin,  Booch,  Rundiaugh,  and  Schlaer-Mellor.  This  method  is  among  the  newest  of  die  group 
and  is  likely  to  undergo  sdll  more  charts.  The  main  advantage  of  diis  method  is  that  it  corrects 
much  of  the  vagueness  in  die  STARS  process,  particularly  in  model  construction  and  definititm. 


ADVANCED  PROJECTS  RESEARCH  AGENCY  (ARPA)  DOMAIN  SPECHIC  SOFT¬ 
WARE  ARCHITECTURES  (DSSA)— COMMAND  AND  CONTROL 


The  DSSA  domain  model  craisisted  of  three  groups  oS  models  tq^lied  in  a  top-down  fashion: 
functional,  (fynamic,  and  object  This  mediod  also  provided  die  most  novel  rq^^licadmi  of  IDEF, 
using  it  to  r^iresem  die  functimial  models  rather  than  die  domain  analysis  {xocess.  The  domain 
model  report  craitained  little  process  informaticxi  and  concentrated  mostly  (Hi  describing  die 
dnee  models  for  the  conunand  and  control  domain. 

The  (fynamic  models  were  represented  using  Requirements  Driven  Design  QtDD)  •  100, 
developed  by  the  Ascoit  Logic  Corporation.  This  method  is  not  widely  known  and  describes 
functk^  processes  in  a  manner  similar  to  the  standard  data  flow  diagram.  The  mediod  also 
allows  (XHttrol  flows  on  the  diagrams  and  indicates  on  diese  flows  if  die  executicHi  may  be  c(hi- 
current  or  sequential  Like  the  data  flow  and  control  flow  diagrams,  RDD-100  offers  a  hierarchi¬ 
cal  decompositi(Hi  of  die  systems  functions. 

The  object  model  uses  the  Object  Modeling  Tbchnique  (OMT)  of  Rumbaugh*  From  an 
object-orioited  stanc^ioint,  the  class  representaticHis  are  quite  standard,  using  an  object/class  dia¬ 
gram  OHitaining  a  ekes  name,  class  attributes,  and  class  functions  or  methods.  The  relaticHiships 
“is  a”  and  ‘Tias  a”  are  leinesoited  with  different  line  c(Hmecti(His  between  the  classes.  Relati(Hi- 
ships  between  classes  are  represented  widi  the  concept  of  an  “association”  between  the  classes. 
Associations  may  have  a  multiplicity,  such  as  a  vdiicle  has  (Hie  or  more  vdieels.  The  technique 
can  display  these  types  of  associations. 

The  dioice  of  object-oriented  analysis  diagramming  method  in  the  DSSA  replication  seems 
flexible.  It  iqpears  that  any  of  die  current  object-oriented  analysis  methods  contain  (hagrams 
capable  of  describing  the  infemnation  contained  in  the  DSSA  Object  Model.  Using  a  different 
method  to  display  the  object  models  would  merely  result  in  slightly  differmt  iK>tati(Hi.  Thus, 
die  use  of  the  Rumbau^  notatitHi  was  not  a  requiremmt  of  dieir  metlKxl;  radier,  it  was  more  of  a 
ctHivenience. 
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